home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / dcom / modems-part1 / 1913 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.0 KB
  1. Path: gate.net!not-for-mail
  2. From: dhaire@gate.net (doug haire)
  3. Newsgroups: comp.dcom.modems
  4. Subject: Re: Supra Modems
  5. Date: 17 Jan 1996 22:40:27 -0500
  6. Organization: CyberGate, Inc.
  7. Message-ID: <4dkffb$fuju@navajo.gate.net>
  8. References: <DL4H42.H2K@news2.new-york.net> <4d9ksu$6fj2@navajo.gate.net> <4dk8sv$h0@news.accessorl.net>
  9. NNTP-Posting-Host: navajo.gate.net
  10. X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
  11.  
  12. Butt-head (eric@eola.ao.net) wrote:
  13. : doug haire (dhaire@gate.net) wrote:
  14. : : brag about. It has what appears to be a problem with not inhibiting the 
  15. : : initiation of a retrain while negotiating error correction. Supra is 
  16. : : currently in denial about this, claiming it doesn't happen, but the 
  17. : : factory default is to inhibit retrain requests (%E0). That means it is 
  18. : : dependent on the remote modem to monitor line conditions and request 
  19. : : retrains. If you set the modem to monitor line conditions and request 
  20. : : retrains (%E1), you then run the risk of it requesting a retrain when it 
  21. : : shouldn't. 
  22. : This is NOT the case.  The retrain that occurs when you actually LOSE 
  23. : CARRIER for awhile is different from the retraining that occurs when the 
  24. : modem "falls backward" or "falls forward".  The modem will request 
  25. : retrains whether you are set on %E0 or %E1, but they are the fall 
  26. : backward/forward kind, not the complete retrains that sound like when the 
  27. : modems are initially establishing a connection.  These take much longer 
  28. : and will sometimes cause timeouts.  If you set S192.5=1 on the Supra, it 
  29. : will display an L followed by an up or down arrow when the local end 
  30. : requests a fall-forward or backward, and display R and an up and down 
  31. : arrow when the remote end requests a retrain.
  32.  
  33. Default settings are %E0 and %G1 and, according to the manual, the %E0
  34. disables the request for retrain while %G1 "On V.32bis connections, as
  35. line conditions change, your modem automatically initiates a Rate 
  36. Renegotiation."
  37.  
  38. Please note the references to "V.32bis". It does not automatically apply 
  39. to V.34 connections and that is where the problem appears. Setting the 
  40. %E1 option, which does not define the V.34 of V.32bis, is said to allow 
  41. the Supra to "monitor line conditions and automatically request a retrain 
  42. if line conditions are bad" (that is the original definition, it is 
  43. slightly different in the newer code but the basic function is the same).
  44.  
  45. In the connections where this problem occurs, the USR will show a Request 
  46. for Retrain received in the ati6 (call analysis) screen. This means that 
  47. the retrain request came from the Supra. Because of the point at which 
  48. the modem connection was dropped (manually), the request is known to come 
  49. during EC/DC negotiation.
  50.  
  51. : : Maybe I've just been spoiled by my USR Couriers but I expect a modem to 
  52. : : function properly and not have a factory default which masks a problem. 
  53. : I've found the factory defaults on the USR's (both Couriers and 
  54. : Sportsters) have trouble with a lot of modems, where the Supras here 
  55. : haven't had problems with any.
  56.  
  57. The USR's have had a terrible time with Rockwell chipset modems. It is 
  58. always Rockwell chipset modems and no other. I have no doubt that you 
  59. accept the factory defaults which limit the Retrain Request in the Supra 
  60. and mask the problem.
  61.  
  62. This problem reminds me of the Hayes problems some time ago where they 
  63. recommended restricting the Retrain Request. Apparently, that has been 
  64. the "fix" for Rockwell chipsets. USR units do not request retrains at 
  65. improper points in the connection (during setup of EC/DC) and do not need 
  66. this work-around.
  67.  
  68. I have run (and still run) a BBS using USR's and beta tested the V.FC and
  69. V.34 and V.34+ codes. The default for the USR (&F1) with only one
  70. modification (s2=255) worked perfectly. I became aware of the problem I 
  71. reported because I switched from a ZyXel (1496+) to a Supra 288 on one 
  72. node (I needed the CID capability).
  73.  
  74. I had one caller who repeatedly connected without error correction until 
  75. I switched that node to another USR. His modem is a GVC, if I recall 
  76. correctly. I also found that I ran into the same problem when calling in 
  77. from my office using my USR.
  78.  
  79. I have switched to the %E0 and now find connections are stable but that I 
  80. regularly get transfer rates for a 26400 rate (receive) even though the 
  81. modem shows a 28800 connect rate (receive) on the display. Does this mean 
  82. that the Supra is falsely reporting a R34/28800 or that it is having 
  83. trouble at that rate and should request a lower speed but doesn't?
  84.  
  85. FWIW, the Supra routinely gives me lower speed connections to most places.
  86. For example, a call to my ISP is regularly a 21600/24000 using the Supra
  87. and never improves but is always a 24000/26400 with fairly regular
  88. upshifts to 26400/26400 using the USR. This is over the same phone line 
  89. on the same computer using the same software.
  90.  
  91. Does anyone know for sure what options are designed for V.34 retrains in 
  92. the Supra?                                              ^^^^
  93.  
  94.  
  95.  
  96.  
  97. -- 
  98.  "Things are more like they are now than they ever were before." 
  99.  [Dwight D. Eisenhower]                                          
  100.